## Problem
The system prompt for saved prompts and workspace rules is too vague,
users reporting they are sometimes ignored entirely.

## Solution
Add system prompt for saved prompt and workspace rules to improve
quality of responses

…put validation exception of supplemental context (#6758)

## Problem
ERROR: `at 'supplementalContexts' failed to satisfy constraint: Member
must have length less than or equal to 5`

ERROR: `supplementalContexts.1.member.content' failed to satisfy
constraint: Member must have length less than or equal to 10240`

## Solution

Jebtrains PR aws/aws-toolkit-jetbrains#5466

     * Requirement
     * - Maximum 5 supplemental context.
     * - Each chunk can't exceed 10240 characters
     * - Sum of all chunks can't exceed 20480 characters

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

…6808)

## Problem
If you have a `.DS_STORE` file in the same directory of the language
server cache versions your language server will crash

## Solution
Only look for valid semver versions when cleaning up your cache

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

## Problem
`collectFiles` and `collectFilesForIndex` serve different purposes, but
implement the same core functionality. This core functionality should be
not duplicated in two places.

## Solution
- Increase testing coverage for both methods. 
- Refactor `collectFiles` to be general enough to handle
`collectFilesForIndex` use case. This includes the ability to avoid
reading the files when we are indexing.
- `collectFilesForIndex` now directly calls `collectIndex` then does its
additional logic with the result.

## Verification
- Tested `@workspace` in chat with some different prompts. Seems to
behave the same as before.
- Tested `/review` on a project. 
---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

The Q product name should find amazon-q-vscode.

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

…e Server (#6811)

## Problem
When running multiple VSCode windows on mac arm64, Amazon Q's language
server works correctly in the first window but crashes in additional
windows with the error: `EXC_CRASH (SIGKILL (Code Signature Invalid))`

## Root Cause
The crash occurs because:
- The first VSCode window starts the language server and extracts
everything (including the node binary from flare)
- When additional VSCode windows are opened, they attempt to re-extract
the zip from flare, overriding the current contents
- On mac arm64, overwriting the node binary while it's in use by the
first VSCode window can apparently cause code signing validation to fail
for the next callers of it
- This didn't effect windows when I was playing around with it yesterday
- Weirdly enough, if you start the language server outside of VSCode,
unzip servers.zip again, and then spawn a new language server it doesn't
seem to have an issue. My guess is there's some weird interplay with
electron owning the spawning of the processes

## Solution
Instead of forcefully overriding contents in flare, only copy over the
file if its necessary

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

feat(amazonq): passing referenceTrackerConfiguration to StartCodeFixJob

## Problem
- We removed chat a while ago from the `feature/amazonqLSP` branch
because we were just starting with inline suggestions

## Solution
- Now that we're moving to use chat we can re-add it
- Implement explain, refactor, fix, optimize, sendToPrompt, openTab
- Add a feature flag for enabling/disabling chat
- **note**: amazonqLSP and amazonqChatLSP must be enabled in order for
chat support to work
- extended the baseinstaller so that individual lsps installers can
provider their own resource paths

## Notes
- this is the equivalent of
https://github.com/aws/language-servers/blob/55253ea258b2d34bcc47b93e9998b1e9898e8f2a/client/vscode/src/chatActivation.ts
but integrated with our codebase
- since commands require the webview we pass in the view provider to all
commands so we can lazy evaluate the webview when required
- certain message listeners are only registered _after_ the UI is
resolved

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

…6791)

## Problem:

With our telemetry, we do not know when the frontend webview UI has
actually loaded.

The current process looks like the following:
- We create a webview and set the HTML to load, but after that we do not
have a formal way to detect if the webview actually loaded the HTML/JS
successfully. We only know that the process started
(`toolkit_willOpenModule`)

## Solution:

Emit certain metrics during the webview loading process to get a better
idea of if the webview UI successfully completed its initial load.

- `toolkit_willOpenModule`, indicates intent to render a webview. It
does not mean the user is seeing anything.
- `toolkit_didLoadModule`, indicates the final result of loading the
webview
- We know a `result: Succeeded` when the frontend send a successful
message to the backend. It knows this by ensuring there were no errors
and that a certain HTML element can be found, then once the page
finishes its initial load it will send a success message to the backend.
- On `result: Failed`, what happens is a timer has timed out after 10
seconds. We assume that since there was no response from the frontend,
it failed to fully execute the HTML/JS.
- State is shared between `toolkit_willOpenModule` and
`toolkit_didLoadModule` so that we can connect them through telemetry.
This includes `traceId` and the `duration` which is the time between the
2 metrics.

This PR only applies to the Login and Reauth page for now, and future
Vue webviews will need to implement some things on their end to get this
functionality.

## TODO
- Generalize this solution in a more robust way for other webviews to
easily implement this functionality

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

---------

Signed-off-by: nkomonen-amazon <[email protected]>

## Problem
The inline completion document selectors between vscode's currently
implementation and the new implementation aren't aligned

## Solution
Rather than providing our own implementation that was originally stolen
from
[here](https://github.com/aws/language-servers/blob/main/client/vscode/src/inlineCompletionActivation.ts#L22)
and expanding it, we should just use the exact document selectors that
vscode already uses from
[here](https://github.com/aws/aws-toolkit-vscode/blob/master/packages/core/src/codewhisperer/models/constants.ts#L104)

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

## Problem
app runner still uses sdkv2. 

## Solution
- Refactor `getServiceSummaries` in `AppRunnerNode` to use SDK native
pagination. This includes updates to the tests for `AppRunnerNode`.
- As is usual with these migrations, build types to account for optional
props.
- Fix bug where wizard displayed node12 as label for node16 runtime. 

## Verification 
- Followed the AppRunner wizard to create an AppRunner deployment
through the toolkit using public ECR
(https://gallery.ecr.aws/aws-containers/hello-app-runner). Followed
similar steps through the console to verify it worked the same way.
- Pause and resume service via explorer. 
- Delete service via explorer. 
- Click in links via explorer.
- used the cwl integration to search log streams associated with
services.
- used the live tail feature on the service (very cool!)

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.